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abstract Program transformations often involve the generalization of a function to take additional arguments 
It is shown that in many cases such an additional variable arises as a representation of the continuation or global 
context in which the function is evaluated. By considering continuations, local transformation strategies can take 
advantage of global knowledge The general results are followed by two examples- the a-p tree pruning algorithm 
and an algorithm for the conversion of a propositional formula to conjunctive normal form 
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1. Introduction 

The notion of program transformation is a programming paradigm which combines the 
notion of stepwise refinement {4, 10, 29] with traditional optimization techniques. Under 
this paradigm, one writes a clear, correct, though possibly inefficient, program, and then 
transforms it via correctness-preserving transformations into a program which is more 
efficient although probably less clear. Some of the classes of program transformations are 
local simplification, partial evaluation (or unfolding), abstraction (or folding), and gener- 
alization [28]. The generalization transformation replaces a function by some generalization 
which may be more amenable to subsequent manipulations. Typical generalizations 
include the introduction of additional variables or the extension of a function to deal with 
a list of inputs. Typical strategies for generalization involve pattern matching between 
compatible but nonidentical goals [1,2, 28]. 

In this paper we present a different strategy for generalizations: the use of continuations. 
A continuation is a data structure which represents the future course of a computation. 
The use of continuations makes the global context of a computation available in the local 
context, and therefore allows the standard local transformations to use this global infor- 
mation. Our strategy is to obtain tractable closed forms for continuations. By studying the 
interactions between a function and its continuation, useful transformations can be made. 

Many of these transformations are probably familiar to assembly-language program- 
mers, since the machine-level programmer usually has access to a continuation variable, 
the run-time stack. Despite this fact, we believe that our account of these techniques is 
useful, since it liberates them from the realm of undocumented “coding tricks” and 
transports them to the source-language level where they can be used by a wider class of 
programmers. Furthermore, we will see that such heuristics as “add an accumulator” or 
“generalize to a list of arguments” may be derived from transformations on continuations, 
rather than being merely instances of isolated cleverness. 
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Section 2 of this paper presents our source language (a dialect of Lisp) and our major 
method of proof, subgoal induction [16]. Section 3 illustrates the notion of a continuation 
and presents examples of the kind of manipulations that are performed on them. In Section 
4 these techniques are applied to the problem of a binary (or tree-structured) recursion 
pattern. In Section 5 our techniques are applied to two moderate-sized examples: the a-f 
tree search algorithm and the conversion of propositional formulas to conjunctive normal 
form. Section 6 presents a summary and conclusion. 

2. Preliminaries 

In this section we describe our language, a syntactically sugared dialect of Lisp, and we 
descnbe the verification method we employ, the method of subgoal induction [28]. 

2. 1 The Source Language. We define functions by recursion equations, e.g., 

F(x, y) <= if p(x) then y .this is a comment 
else a(b(x),F(c(x),y)) 

This style of definition has a long history [14, 15, 21]. We often use sets of simultaneous 
recursion equations. We usually use uppercase for the names of functions we are defining 
(e.g., F above) and lowercase for functions which are assumed elementary (e.g., a, b, c, and 
p above). Such functions are often left unspecified. We refer to these functions as trivial 
and to the ones we define by equations as serious [19]. Occasionally we use the arithmetic 
functions, which we write in infix notation. End-of-line comments are preceded with 
semicolons. Side effects are not permitted. 

We will have occasion to use list processing, for which we use notation adapted from 
[7J. If x,y, and z are variables, [xy z] denotes a list whose three elements are the values of 

x, y, and z. If the value of y is a list of N elements, then the value of [x !y] is a list of 
N + 1 elements whose first element is x and the remainder of whose elements are those of 

y. We use hd and tl to select the first element of a list and its remainder; thus 

hd([x\y]) = x, tl{[x\y\) =y, 
hd([x y z]) = x, tl([x y z]) = [yz]. 

Similarly, [xylz] denotes a list whose first two elements are equal to x and y, and 
whose remainder is equal to z. [ ] denotes the empty list. The function appendix, y) con- 
catenates two lists nondestructive^; append is associative, so we will sometimes write 
appendix, y, z). 

We will also occasionally use temporary functional objects passed as arguments. Such 
objects, called closures, are created using \-notation. For example, the definition 

F(x, y) <= MAPHD(\z [x ' z], y) 

MAPHD(f, x) «= if x = [ ] then [ ] 

else \f(hd(x)) ' MAPHD(f, //(*))] 

passes a functional object as a parameter to MAPHD. The value of x inside the closure is 
the value at the time the closure was created; that is, we use lexical or static scoping [17, 
26], Thus FI 3, [[I] [2] [3]]) evaluates to [[3 1] [3 2] [3 3]]. MAPHD is a generally useful 
function which we shall take as pnmitive Another useful function is MAPI which is 
defined as 

MAP'tfa , x) e= if x = [ J then a 

else f(hd(x), MAP\f, a, tl(x))) 

where / is a function of two arguments; MAP'lsum, 0, x) returns the sum of the elements 
of x. 

2 2 Subgoal Induction Our major method for proving properties about recursion 
equations is the method of subgoal induction [16], which is an easily understood refinement 
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of earlier methods [13, 14]. For each serious function F(x,y), we introduce an input-output 
specification fa(x, y, z) which is a condition on the input parameters x, y and the output 
value z. The principle of subgoal induction states that if the verification conditions (which 
we are about to describe) are true, then the function satisfies its specifications, that is, if F 
halts on input (x, y), then tp F (x, y, F(x, /)) is true. There is one verification condition for 
each branch of the equation. The verification condition for each branch has the form 
A & B & C =* D, where A is the condition for taking that branch, B says that all serious 
function calls on this branch satisfy their specifications, C says that equal arguments to a 
serious function give equal answers, and D says that the final value on this branch satisfies 
the desired specification. New variables are introduced throughout to eliminate all occur- 
rences of serious function symbols. For example, 

F(x) <= if p(x) then a(x) 

else b(F(I(x)), Ffrfx))) 

produces the verification conditions 

Vx[p(x) =*• <Hx; o(x»], 

VxVz 1 Vz 2 [~p(x) & «K/(x); Zi) & » HrQc); z 2 ) & [/(x) = r(x) -ha - z 2 ] -* +(x; b{z u *))]. 

In the second condition the second and third conjuncts comprise formula B. The “func- 
tionality” condition C is not used in this paper but is useful for specifications which would 
otherwise be too weak to support the induction. Extensions to multiple equations are 
obvious, as are those to multiple-valued and nondeterministic functions. In our experience 
this is a powerful and natural method for explaining the correctness of recursive programs. 
Although subgoal induction is a partial correctness method, it can be extended to prove 
total correctness by including a performance measure in the specifications, just as the 
inductive assertion method can be so augmented [11]. 

3. Manipulating Continuations 

To illustrate the notion of a continuation, let us consider a function which reverses a list: 
Program 3.1 

REV(x) <= if x = [ ] then [ ] 

else append(REV(tl(x )), \hd(x)\) 

If REV is called with a nonnil list x, it proceeds to call REV on tl(x)\ given the value of 
REV(tl(x)), say w, the resulting answer is append{w, [Ad(x)]). Another way of expressing 
this idea is that the function \w.append(w, [hd{x)]) is applied to the argument REV{tl(x)). 
The function \w.append(w, [hd(x)]) is called the continuation [5, 6, 19, 20, 22-24, 26]. We 
can use this idea to rewrite RE V in the so-called continuation-passing style: 

Program 3 2 

REV2(x) e= REVC{x, \z z) 

REVC(x, y) «= ,= y(REV(x)) (see footnote 1) 

if x = 1 ] then v(l ]) 

else REVC(tl(x ), Atv y(append(w, [A<f(x)]))) 

Here the intended input-output specification is included as a comment. 

In order to fix our ideas about subgoal induction as a device for program explanation/ 
verification, let us prove: 

Proposition 3. 1 . REVCQc, y) = y(REV(x)). 

1 ,= may be read “is intended to equal.” 
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Proof. The specification \Prevc(x, y; z) is z = y(REV(xj). The verification conditions 
are 

(0 (* = □)=» ypREvc(x, Y, Y([ ])) and 

(ii) (x ^ [ ]) & \pREvc(tl(x), \w.y(append(w, [>W(x)])); z) => 4>revc(x, y, z). 

Substituting the definition of ^revc, we have to show 
(i) (* = [])=» (y([ ]) = y(REV(x))% 

( 11 ) (x * [ ]) & (z = (Xw.y(append(w, [hd(x)])))(REV(tl(x)))) => (z = y(REV(x))). 
Verification condition (i) follows immediately from the definition of REV. Condition (ii) 
is proved as follows: 

(x * [ ]) & (z = (\w.(append(w, [ hd(x)])))(REV(tl(x )))) 

=> (x ^ [ ]) & (z = y(append(RE V(tl(x)), [/id(x)]))) (8-reduction 2 ) 

=» z = y(REK(x)) (definition of using x^[]). □ 

The use of subgoal induction lets us prove the correctness of REVC essentially “line by 
line,” referring to the definition of REV and doing some simple manipulations. Henceforth, 
proofs of this sort will be left to the reader; the relevant input-output specification will be 
included as a comment. 3 Similarly, it is evident that if REV terminates (which it always 
does), then so does REVC. This may be proved by considering the performance specifi- 
cation 

' Prevc(x , y; z) ■ if y occurs as a first argument to REVC during the computation of 
REVC(x, y), then y occurs as a first argument to REV during the 
computation of REV{x). 

A brief consideration of the usual operational semantics of recursion equations (using, say, 
call-by-value) reveals that this specification is inconsistent with nontermination. Similar 
arguments throughout will be left to the diligent reader. 

Let us now make another observation about the operational semantics of REVC. 
In the computation of REV2(x), every value of y supplied to REVC is of the form 
Xv.append(v, a) for some a. To prove this, we observe that Xz.z is of this form (with 
a = [ ]), and if y = Xv.append(y, a), then 
Xw.y(append(w, f/irf(x)])) 

= Xw.((Xv.append(v, aj)(append(w, [Ad(x)]))) (definition of y) 

= Xw.append{append(w, [hd(xj\), a) (6-reduction) 

= Xw.append(w, append([hd(x)], a)) (associativity) 

= Xw.append(w, [hd{x) ! a]) (fact about append). 

Hence, instead of carrying around the function y, we can carry around the list a which 
represents it. Instead of writing y([ ]), we can write append ([ ], a) or just a. This gives us 

Program 3.3 

R£K3(x) <= REVC3(x , [ ]) 

RE VC3(x, a) <= ,= append(RE V{x), a) 

ifx = []thena 
else REVC3(tl(x ), [hd(x) ' a]) 

which is just the usual “iterative reverse with accumulator.” This leads us to our key 
observation: An accumulator is often just a data structure representing a continuation 
function , 4 Data structures representing functions of some restricted type are widespread. A 
closure is of course a data structure; an association list is a representation of a function 

2 The operation of /{-reduction replaces an expression of the form (Ar t)a by t, with a substituted for all free 
occurrences of v> 

3 Just as one should include one’s invariants as comments. 

4 It would be nice to turn this observation into a theorem by replacing the word “often” by “always ” That, 
unfortunately, would require a formal definition of an “accumulator,” which is quite beyond the scope of this 
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if p(x) then a(x ) 
else b(F(c(x)), d(x)) 

where b is associative, with right identity 1 4 , is replaced by 
F'(x) <= FQx, L) 

FC{x, Y ) «= ,= b(F(x), Y ) 

ifp(x) then b(a(x), y) 
else FC(c(x), W y)) 

Fig 1 Replacement of associative continuation builder by accumulator 

from keys to values when the keys are atoms; 8 and the run-time stack is a machine-level 
representation of the top-level continuation [e.g., 19, 26], Indeed, the identifier environment 
in which a program is run can be any data structure which can be used to map keys to 
values; even the form of the keys can be made arbitrary by preprocessing (see [22]). 

It is worthwhile to state Proposition 3.1 as a general transformation (Figure 1). 

Proposition 3.2. In Figure 1, F\ x) - F(x). 

Proof. By subgoal induction on FC. The interesting case is ~p(x): 

FC(x, y) = FC(c(x), b{d(x), y)) 

= b(F(c(x)), b(d(x), y)) (induction hypothesis) 

= b(b(F(c(x)), d(x)), y) (associativity of b) 

= b(F(x), y). (definition of F). □ 

This transformation is well known; what is new in our discussion is the relationship 
between the accumulator and the continuation. 

Similar transformations for the nonassociative case have been considered by Strong 
[25], Let us take, for an example, McCarthy’s 91 -function: 

Program 3 4 
F(x)<= 

if x > 100 then x - 10 else F(F(x +11)) 

In continuation form this becomes 

Program 3 5 

F2(x) <= F2-C(x, \z z) 

F2-C(x, y) *= . = y(F(x)) 

if x > 100 then y(x - 10) 
else F2-C(x + 1 1, \n> y(F(w))) 

Here again, we can obtain a closed form for the continuation: It is always of the form 
Xw.F(F(F- ■ ■ (w))) for some number of F’s. Hence we can represent the continuation by a 
counter. Unfortunately, it is more difficult to simulate y(x - 10) in this representation. To 
do this, we write a special function F3-SEND which simulates functional application for 
the given representation of the continuation: 

Program 3 6 
Fi(x) <= F3-C(x, 0) 

F3-C(x, i) <= = F u, (F(x)) 

if x > 100 then F3-SEND(x - 10, i) 
else F3-C(x+ 11, i+ 1) 

F3-SEND(v, i) <= ,= F“(v) 

if i = 0 then v ;the identity continuation 
else F3-C(v, i - 1) 

(Compare [12, Problem 3-5]). 

If more is known about the function, then a more finely optimized representation may be used, e g , a binary 
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When less is known about the continuation builders, then the representation of the 
continuation will perforce be less compact. In previous work we have considered the case 
where nothing whatsoever is known [27], Another case, also studied by Strong [25], is that 
of a single continuation builder with a parameter: 

Program 3 7 

if p(x) then a(x) 
else if q(x) then F(b(x)) 
else c(d(x), F(e(x))) 



Introducing continuations, we get 

Program 3 8 
F2(x) <= F2-C(x, Xz z) 

F2-C(x, y) <= ,= y(F(x)) 

if p(x) then y(a(x)) 

else if q(x) then F2-C(b(x), y) 
else F2-C(e(x), \w y (c(<i(jc), w))) 

Here again, we know a closed form for the continuation: 

\w.c(a u c(a 2 , .... c(a n , w))). 

We can represent this continuation by [a„ a„-i • • • oi], giving 

Program 3 9 

Fl(x) «= F3-C(x, [ ]) 

F2-C(x, y) «= 

if p(x) then F3-SEN D(a(x), y) 
else if q{x) then F3-C{b(x), y) 
else F2-C(e(x), \d(x) ' y]) 

F3-SEND(v, y) <= 
if y = [ ] then r 

else F3-SEN D(c(hd(y), v), l/(y)) 

This is the well-known technique of replacing a single return address by a data stack [10, 
25]. 6 We chose to reverse the a,’s in the representation of the continuation so that the 
transformations of building and decomposing the continuations would be easily imple- 
mented in our list processing primitives. 

The correctness proof for (3.9) is not quite so straightforward as that for (3.8). In 
(3.8) we had the specification F2-C(x, y) = y(F(x)), In (3 9) y is no longer a function 
but is rather its representation. Hence the corresponding specification is F3-C(x, y) = 
F3-SEND(F(x), y). 

Proposition 3.3. For all x and y, F2-C(x, y) = F3-SEND(F(x), y). 

Proof. By subgoal induction on F. If p(x), then 

F3-C(x, y) = F3-SEND(a(x), y) (definition of F3-C) 

= F3-SEND(F(x), y) (definition of F). 



Otherwise, if q(x), then 

F3-C(x, y) = F3-C(b(x), y) (definition of F3-C) 

= F3-SEN D(F(b(x)), y) (induction hypothesis) 

= F3-SEND(F(x), y) (definition of F). 

6 Note that in the original definition of F there were two recursive calls on F. The first of these, however, was tail- 
recursive, and so corresponds to the identity transformation on continuations Similarly, tail-recursive lines could 
be added to any of our examples without requiring global modifications 




